1. Field of the Invention
The present invention is in the field of computers and signal processing systems and circuits. More particularly, the invention is in the field of interfacing with peripherals through a codec.
2. Background Art
A codec (COder-DECoder) is a circuit that converts analog signals to digital code and vice versa using conversion methods such as PCM (Pulse Code Modulation). A codec typically includes both analog to digital and digital to analog conversion circuits. FIG. 1 is a prior art diagram illustrating how a codec might be connected to a motherboard and in particular to a controller. Motherboard 110 is a modem PC motherboard. System logic 112 resides on motherboard 110 and is coupled to the remaining components on the motherboard primarily through a PCI (Peripheral Component Interconnect) bus 114. A host CPU (not shown in any of the Figures) is typically located in system logic 112. Controller 116 communicates with system logic 112 through PCI bus 114. In FIG. 1, controller 116 is shown as a stand-alone device. However, controller 116 could be embedded or incorporated into other portions of the PC system including the system logic.
A riser 128 houses other components in FIG. 1. Riser 128 complies with the industry""s standard specification for an Audio/Modem Riser (or xe2x80x9cAMRxe2x80x9d). The AMR specification defines an industry standard form factor for Audio, Audio/Modem or just Modem risers. The AMR specification defines riser mechanical and electrical requirements for certain systems using what is called an AC-link (xe2x80x9cAudio Codec linkxe2x80x9d) interface as one of the connections between the riser and the motherboard.
Referring to FIG. 1, riser 128 includes codec 126. When riser 128 is plugged into motherboard 110, codec 126 communicates with controller 116 through AC-link 124, AMR interface connectors 122 and 120, and AC-link 118. Alternatively, the combination of AC-link 124, AMR interface connectors 122 and 120, and AC-link 118 can be thought of simply as a single AC-link connecting controller 116 to codec 126.
Reference is made to FIG. 2 which shows controller 216 that is coupled to codec 226 through AC-link 218. Codec 226 includes codec register set 230. Codec register set 230 is utilized by system and circuit design engineers for various control functions such as for configuring the codec or for setting up the codec to record a certain input such as a CD ROM input. As further examples, the registers in codec register set 230 are used for setting headphone volume, PC beep volume, microphone volume, CD volume, video volume, record gain, 3D control, audio status, audio sample rate control, modem status, modem DAC/ADC level control, GPIO (General Purpose Input/Output) pin configuration, GPIO pin polarity and type, power management, as well as many other codec functions.
Typical codecs, such as those complying with the Intel(copyright) AC ""97 specification entitled xe2x80x9cAC ""97 Component Specification,xe2x80x9d Revision 2.1, published by Intel(copyright) Corporation on May 22, 1998 (or simply xe2x80x9cAC ""97 specificationxe2x80x9d), have been designed to perform primarily audio related functions. However, it has become increasingly important for codecs, such as those complying with AC ""97 specification, to perform primarily modem related functions. Modem related functions can require additional modules and peripherals to be controlled by the controller. An example of when an additional module or peripheral and its respective set of registers need to be addressed and controlled through the AC-link is when it is desired to perform a DSP (xe2x80x9cDigital Signal Processingxe2x80x9d) function, such as acoustic echo cancellation, at a point beyond the AC-link and the codec (as opposed to performing the echo cancellation in the controller itself).
Other examples of additional modules or peripherals and their respective sets of registers that need to be addressed and controlled through the AC-link are an LSD (xe2x80x9cLine Side Devicexe2x80x9d), an SSD (xe2x80x9cSystem Side Devicexe2x80x9d), and an E-PHY (xe2x80x9cEthernet PHYsical-layer interfacexe2x80x9d) device. By way of background, an LSD is a module or peripheral that has been recently devised and added by some manufacturers to a Data Access Arrangement (xe2x80x9cDAAxe2x80x9d) device in order to facilitate the interfacing of the DAA with a codec. A DAA is a peripheral that is widely used in the art and is conventionally comprised of discrete components used to interface with a telephone line. As stated above, recently, the LSD has been added as a module in the DAA to facilitate interfacing between the DAA and a codec. With the recent addition of the LSD to the DAA by some manufacturers, the DAA is comprised of two main modules which are (a) the discrete component module, and (b) the LSD.
The addition of the LSD to the DAA has resulted in the need for addition of a module inside the codec to interface with the LSD. The module inside the codec is the SSD. The interface between the LSD which is outside the codec and the SSD which is inside the codec is performed through what is referred to as a Digital Isolation Barrier (xe2x80x9cDIBxe2x80x9d). The addition of the LSD and the SSD as recent modules that facilitate codec operations and which facilitate the codec interfacing with a telephone line, has given rise to the need to address and control these recently added modules, namely the LSD and the SSD, through the AC-link and the codec. It is noted that an SSD may also be a module separate from (as opposed to integrated in) the codec. An E-PHY is a device that performs Ethernet related functions in a LAN (xe2x80x9cLocal Area Networkxe2x80x9d). The E-PHY may be integrated in the codec or, alternatively, the E-PHY may be a module separate from the codec. Each of these modules or peripherals, e.g. the SSD, LSD, and E-PHY, has a respective set of registers which needs to be addressed and controlled by the controller through the AC-link.
As stated above, in each of the above examples the controller is required to address and control a bank of registers that are accessible to the controller only through the AC-link and the codec. In other words, in order to access modules or peripherals that are located xe2x80x9cbeyondxe2x80x9d the AC-link, the controller must go through both the AC-link and the codec. As such, the controller must comply with the requirements of the AC-link. The requirements of the AC-link stem, in part, from a predetermined timing protocol for AC-link communications, i.e. for communications between the controller and the codec through the AC-link.
One specific requirement of an AC-link complying with the AC ""97 specification has to do with timing and speed requirements for reading data by the controller from a register or a peripheral located across the AC-link. Transmission of data between controller 216 and codec 226 through AC-link 218 is performed in 12 outgoing or incoming xe2x80x9cslotsxe2x80x9d following an initial xe2x80x9cTAGxe2x80x9d slot. According to the AC ""97 specification, each xe2x80x9cslotxe2x80x9d contains up to twenty bits of information used for communication across AC-link 218. The 12 slots following the TAG slot comprise a xe2x80x9cframe.xe2x80x9d The standard rate of transmission of frames through AC-link 218, according to the AC ""97 specification, is 48 KHz. In other words, in approximately every 20.8 microseconds, a frame is transmitted across AC-link 218. This rate of transmission of frames across the AC-link is not adjustable for codecs complying with the AC ""97 specification.
Moreover, the AC ""97 specification imposes an exacting requirement that all read data be returned in the very next frame following the frame in which the read data was requested. In other words, when controller 216 makes a request to read a register located across AC-link 218, the data from the addressed register must be returned to the controller in the very next frame, i.e. within approximately 20.8 microseconds from the read request.
This exacting standard poses a major problem when data to be read is not available because the register addressed is located in a slow peripheral across the AC-link. If a register in a peripheral or module that is located xe2x80x9cbeyondxe2x80x9d the AC-link is accessed by the controller through the AC-link, the controller still expects the read data to be returned in the very next frame following the data request frame. This would leave no more than approximately 20.8 microseconds for the read data to be transferred, from the slow peripheral to the controller. A peripheral or module, such as the LSD, communicating with the codec through the DIB is an example of a slow peripheral. Communications between the codec and LSD through the DIB occur at a frame rate of 16 KHz. Thus, the delay associated with obtaining the read data from a register located in the LSD is too large to have the read data ready and transmitted through the AC-link to the controller while complying with the AC-link""s 48 KHz frame rate.
If the read data is not available to the controller requesting the data at the rate of 48 KHz (i.e. in approximately 20.8 microseconds after the request was made), the controller and the host CPU would have to keep polling the codec to find out when valid data is finally available. Thus, in order to retrieve the data requested from a slow peripheral, such as the DIB and LSD combination stated above, the software running in the host CPU must continually poll the codec to find out whether the read data has been passed from the LSD to the codec. This polling process would occupy the host CPU for a very long time. In the example given above, the host CPU must idle for 62.5 microseconds corresponding to the 16 KHz frame rate of the DIB and LSD combination. For modern CPUs operating at speeds over 500 MHz, idling for 62.5 microseconds is a huge waste of CPU time and power. Moreover, during this idling period, the entire system would slow down and a large global delay is introduced in all the various functions to be performed by the host CPU.
Although the problems encountered by a host CPU and a controller in interfacing with a slow peripheral across the AC-link was described by referring to a read operation, similar problems exist when a host CPU and a controller are performing a write into a slow peripheral through the AC-link. In other words, when the peripheral is slow, the host CPU must wait for the write operation to be completed prior to executing another transaction (either another write or a read operation) with the slow peripheral. Thus, as was the case when read data was requested from the slow peripheral, a write into the slow peripheral through the AC-link would require the controller and the host CPU to keep polling the codec to find out when the write operation has been completed and when the slow peripheral is ready for another transaction.
Thus, there is serious need in the art for resolving the problem faced by a host CPU and a controller needing to read data from or write data into a slow peripheral located beyond the AC-link and the codec. In other words, there is serious need in the art to resolve the problem of the controller and host CPU awaiting, for too long, receipt of data from a slow peripheral through the AC-link and the codec or waiting, for too long, the completion of a write into the slow peripheral through the AC-link and the codec. Also, there is need in the art for a method and apparatus that permits the software running on the host CPU to continue to function in a normal manner and run other applications despite the long response time of the slow peripheral in performing read or write operations.
The present invention is a method and apparatus for facilitating AC-link communications between a controller and a slow peripheral of a codec. The invention resolves the problem faced by a host CPU and a controller needing to read data from or write data into a slow peripheral located beyond the AC-link and the codec. That is the invention resolves the problem of the controller and host CPU awaiting, for too long, receipt of data from a slow peripheral through the AC-link and the codec or waiting, for too long, the completion of a write into the slow peripheral through the AC-link and the codec. The invention is a method and apparatus that permits the software running on the host CPU to continue to function in a normal manner and run other applications despite the long response time of the slow peripheral in performing read or write operations.
In one embodiment, the invention utilizes the GPIO_INT bit (i.e. bit 0 in slot 12 in the AC-link""s SDATA_IN line) as an interrupt flag to indicate when data requested by the controller from the slow peripheral is returned and is available to be read by the controller. The GPIO_INT bit can also be used to indicate when a write into the slow peripheral is completed. In this embodiment, a xe2x80x9cperipheral ready bitxe2x80x9d or a xe2x80x9cperipheral ready signalxe2x80x9d originated from the slow peripheral is used to set the GPIO_INT bit.
In another embodiment, the invention is directed to controllers which ignore the GPIO_INT bit as a source of interrupt. In order to accommodate these controllers, the invention uses one of the GPIO bits to send the value of the xe2x80x9cperipheral ready bitxe2x80x9d to the controller. Upon receipt of the peripheral ready bit as one of the GPIO bits from the codec, the controller would interrupt the host CPU and the host CPU is made aware that the data requested from the slow peripheral is returned and is available to be read. The GPIO bit can also be used to indicate that a write into the slow peripheral has been completed.
In yet another embodiment of the invention, the software running on the host CPU successively checks the peripheral ready bit, which is a designated bit in one of the codec""s vendor reserved registers, to find out when the peripheral ready bit has been set. When the peripheral ready bit is set, and so detected by the software, the software would be alerted to the fact that the register from which data was requested now contains the requested data, and the requested data is then read by the software. The designated bit can also be used to indicate that a write into the slow peripheral has been completed.